Same here, occurs often now when different Firefox installs are being used at the same time.

As a workaround until this gets fixed, W10 users should try out Eartrumpet [1], its more intuitive than Windows' volume mixer.

[1] https://www.microsoft.com/en-us/p/eartrumpet/9nblggh516xp

intuitive, yes, but Eartrumpet volume overview also always opens in upper left corner of screen instead of last position at moment of closing. :/

Hello?
taps the microphone
Is this thing on?

https://i.imgur.com/8BVdG3z.png

This is fixed in current Nightly builds.

Nope, not for me...

(In reply to Dan from comment #20)

Nope, not for me...

It'd be helpful to provide more information. What is the build ID of the Nightly build you tested?

still occuring on 20200221214911. I open a new tab (YouTube), a new slider is added.

(In reply to Dan from comment #22)

still occuring on 20200221214911. I open a new tab (YouTube), a new slider is added.

If you check about:config, is media.cubeb.sandbox set to true?

Have seen two posts on Reddit recently where people with older version of Windows 10 (1809) still have this bug, never seen anyone with this on a newer version of Windows 10.

Dan, is your Windows 10 version 1809 or older than 1909? Right click Start menu > System.

yes set to true. yes, I'm on 1903.

Note that sndvol seems to continue displaying unused/dead volume controls for some time after they're unused (possibly until sndvol is restarted?). If I leave sndvol open and restart Firefox, I can see two Firefox volume control entries... but only one is used, and restarting sndvol shows only a single Firefox volume control remains.

Looks like Bug 1432303, which covers audio (cubeb) remoting on Windows, is now landed in trunk. I believe this means that we no longer need to generate sound from the content process. If so, we can stop initializing an AudioSession in content processes, which should make this problem go away (save, possibly for a volume control for Flash use in the plugin process). I'm going to try that and see what happens.

AudioSession, which handles things like making sure that the volume slider in the system tray has the right name and icon and is aligned for all processes, is not needed in content processes any longer since bug 1432303 remoted audio use away from content.

We are running into some dangeous internal locking behavior in _endthreadex when shutting down the monitor_device_notifications thread in Windows Audio IPC. To avoid deadlock, this patch uses its own Windows Event to synchronize the death of that thread with the Audio IPC Server thread that governs its shutdown.

Depends on D64445

Removing the AudioSession from content processes fixes this issue. In trying out a bunch of audio stuff, I regularly hit a cubeb IPC hang at shutdown. I wouldn't be surprised if this is the cause of Bug 1610640. I suspect it's related to (but not the same as) this [1]. The deal for me is that the "Audio IPC Server RPC" thread is doing this:

  ntdll.dll!NtWaitForSingleObject()  Unknown
  KernelBase.dll!WaitForSingleObjectEx() Unknown
  xul.dll!monitor_device_notifications::~monitor_device_notifications() Line 352  C++
  [Inline Frame] xul.dll!wasapi_collection_notification_client::~wasapi_collection_notification_client() Line 511 C++
  xul.dll!wasapi_collection_notification_client::~wasapi_collection_notification_client() Line 511  C++
  xul.dll!wasapi_collection_notification_client::Release() Line 483 C++
  [Inline Frame] xul.dll!`anonymous namespace'::com_ptr<wasapi_collection_notification_client>::release() Line 167  C++
  [Inline Frame] xul.dll!`anonymous namespace'::com_ptr<wasapi_collection_notification_client>::~com_ptr() Line 123 C++
  [Inline Frame] xul.dll!cubeb::~cubeb() Line 189 C++
  xul.dll!`anonymous namespace'::wasapi_destroy(cubeb * context=0x00000212e34d9b80) Line 1581 C++
  xul.dll!core::ptr::real_drop_in_place<audioipc_server::server::CubebContextState>(audioipc_server::server::CubebContextState *=0x00000059e14bf4c8) Line 175 Unknown
  xul.dll!std::thread::local::fast::destroy_value<core::cell::RefCell<core::option::Option<audioipc_server::server::CubebContextState>>>(unsigned char * ptr) Line 470  Unknown
  xul.dll!std::sys_common::thread_local::register_dtor_fallback::run_dtors() Line 257 Unknown
  [Inline Frame] xul.dll!std::sys::windows::thread_local::run_dtors() Line 234  Unknown
  xul.dll!std::sys::windows::thread_local::on_tls_callback() Line 205 Unknown
  ntdll.dll!LdrpCallInitRoutine() Unknown
  ntdll.dll!LdrpCallTlsInitializers()  Unknown
  ntdll.dll!LdrShutdownThread() Unknown
  ntdll.dll!RtlExitUserThread()  Unknown
  kernel32.dll!BaseThreadInitThunk() Unknown
  ntdll.dll!RtlUserThreadStart() Unknown

while the monitor_device_notifications child thread is hung in _endthreadex, which is implicitly called when the thread function thread_proc is exited:

  ntdll.dll!NtWaitForSingleObject()  Unknown
  ntdll.dll!LdrpDrainWorkQueue()  Unknown
  ntdll.dll!LdrShutdownThread() Unknown
  ntdll.dll!RtlExitUserThread()  Unknown
  KernelBase.dll!FreeLibraryAndExitThread() Unknown
  ucrtbase.dll!common_end_thread()  Unknown
  ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>()  Unknown
  kernel32.dll!BaseThreadInitThunk() Unknown
  ntdll.dll!RtlUserThreadStart() Unknown

(The impl for _endthreadex just immediately jmps to common_end_thread). Note that its hanging in FreeLibraryAndExitThread, which is what the DLLInit issue in [1] is about -- but you aren't in DLLInit in any way I can see. I get this hang every time I go to [2], start a webrtc session, stop it, and then shut down (with a new profile).

I don't know what DLL it is trying to unload but it probably doesn't matter -- there are apparently some undocumented locks used in the implementation of these functions that wreak all kinds of havok on people's code. I don't see where you are doing anything with LoadLibrary that should be related so its probably a superfluous (to your case) lock. Things that come from nowhere are hard to reason about.

FYI, the unload may need something from the main thread, which is stuck doing this:

  ntdll.dll!NtWaitForSingleObject()  Unknown
  KernelBase.dll!WaitForSingleObjectEx() Unknown
  xul.dll!std::sys::windows::thread::Thread::join() Line 62 Unknown
> xul.dll!std::thread::JoinInner<()>::join<()>() Line 1326  Unknown
  xul.dll!std::thread::JoinHandle<()>::join<()>(std::thread::JoinHandle<()> self) Line 1457 Unknown
  xul.dll!audioipc::core::{{impl}}::drop(audioipc::core::CoreThread * self) Line 34 Unknown
  xul.dll!core::ptr::real_drop_in_place<audioipc::core::CoreThread>(audioipc::core::CoreThread *=0x000001fd68dbed90) Line 175 Unknown
  xul.dll!core::ptr::real_drop_in_place<audioipc_server::ServerWrapper>(audioipc_server::ServerWrapper *=0x000001fd68dbed90) Line 175 Unknown
  xul.dll!core::ptr::real_drop_in_place<alloc::boxed::Box<audioipc_server::ServerWrapper>>(audioipc_server::ServerWrapper * *=0x000000752adff0f8) Line 175  Unknown
  xul.dll!core::mem::drop<alloc::boxed::Box<audioipc_server::ServerWrapper>>(audioipc_server::ServerWrapper * _x=0x000001fd68dbed90) Line 704 Unknown
  [Inline Frame] xul.dll!mozilla::`anonymous namespace'::ShutdownAudioIPCServer() Line 164  C++
  xul.dll!mozilla::CubebUtils::ShutdownLibrary() Line 635 C++
  xul.dll!nsLayoutStatics::Shutdown() Line 384  C++
  [Inline Frame] xul.dll!nsLayoutStatics::Release() Line 44 C++
  [Inline Frame] xul.dll!Shutdown() Line 127  C++
  xul.dll!nsLayoutModuleDtor() Line 262 C++
  xul.dll!nsComponentManagerImpl::Shutdown() Line 935 C++
  xul.dll!mozilla::ShutdownXPCOM(nsIServiceManager * aServMgr) Line 727 C++
  xul.dll!ScopedXPCOMStartup::~ScopedXPCOMStartup() Line 1231 C++
  [Inline Frame] xul.dll!mozilla::DefaultDelete<ScopedXPCOMStartup>::operator()(ScopedXPCOMStartup * aPtr=0x000001fd68d770f0) Line 487  C++
  [Inline Frame] xul.dll!mozilla::UniquePtr<ScopedXPCOMStartup,mozilla::DefaultDelete<ScopedXPCOMStartup>>::reset(ScopedXPCOMStartup * aPtr) Line 324 C++
  [Inline Frame] xul.dll!mozilla::UniquePtr<ScopedXPCOMStartup,mozilla::DefaultDelete<ScopedXPCOMStartup>>::operator=(void *) Line 297  C++
  xul.dll!XREMain::XRE_main(int argc, char * * argv, const mozilla::BootstrapConfig & aConfig={...}) Line 4718  C++
  xul.dll!XRE_main(int argc, char * * argv, const mozilla::BootstrapConfig & aConfig) Line 4752 C++
  [Inline Frame] firefox.exe!do_main(int argc, char * * argv=0x000001fd68d0a060, char * * envp=0x000001fd66e77b60) Line 217 C++
  firefox.exe!NS_internal_main(int argc=0x00000003, char * * argv, char * * envp=0x000001fd66e77b60) Line 331 C++
  firefox.exe!wmain(int argc, wchar_t * * argv=0x000001fd66e66490) Line 131 C++
  [Inline Frame] firefox.exe!invoke_main() Line 90  C++
  firefox.exe!__scrt_common_main_seh() Line 288 C++
  kernel32.dll!BaseThreadInitThunk() Unknown
  ntdll.dll!RtlUserThreadStart() Unknown

I avoid this by replacing [3] with a wait on a new Event that is signaled in thread_proc when you get the shutdown event (same idea as the shutdown Event but in the other direction). That should work and avoid whatever these undocumented locks are up to. This will also fix Bug 1614585, although I intend to land the fix I mention in Bug 1614585 comment 2, because I believe the issue still exists with plugin and main processes, even though we don't see crash stacks for them (yet).

[1] https://stackoverflow.com/a/10557979/88804
[2] https://janus.conf.meetecho.com/echotest.html
[3] https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/media/libcubeb/src/cubeb_wasapi.cpp#350

We are running into some dangeous internal locking behavior in _endthreadex when shutting down the monitor_device_notifications thread in Windows Audio IPC. To avoid deadlock, this patch uses its own Windows Event to synchronize the death of that thread with the Audio IPC Server thread that governs its shutdown.

Depends on D64445

I'm having trouble getting clang-format to respect the fact that media/libcubeb is in the .clang-format-ignore file and shouldn't be auto formatted. So Part 2 is still a WIP.
sigh.

(In reply to David Parks (dparks) [:handyman] from comment #30)

In trying out a bunch of audio stuff, I regularly hit a cubeb IPC hang at shutdown. I wouldn't be surprised if this is the cause of Bug 1610640.

Bug 1610640 seems to have exited AudioIPC before the hang occurs (at least, it has bailed further than any logging I had in place). To verify, I did a quick try run with AudioIPC re-enabled in b-c and with your patch applied (just D64451) - unfortunately bc6 still hangs on shutdown. I'll try again with D64445 included, just in case (edit: no difference, still hangs).

(In reply to Matthew Gregan [:kinetik] from comment #33)

(In reply to David Parks (dparks) [:handyman] from comment #30)

In trying out a bunch of audio stuff, I regularly hit a cubeb IPC hang at shutdown. I wouldn't be surprised if this is the cause of Bug 1610640.

Bug 1610640 seems to have exited AudioIPC before the hang occurs (at least, it has bailed further than any logging I had in place). To verify, I did a quick try run with AudioIPC re-enabled in b-c and with your patch applied (just D64451) - unfortunately bc6 still hangs on shutdown. I'll try again with D64445 included, just in case (edit: no difference, still hangs).

Yeah, I wouldn't be surprised if this is not the cause of bug 1610640 either. Would have been nice though. D64445 dramatically changes the performance profile of the Windows behavior in audio shutdown, which is what I assume led to the hang I saw (I've got no other sane explanation for why removing AudioSession from content would cause a hang in the main process). If adding it makes a difference to bug 1610640, its probably more of a coincidence than anything.

Upstream. Derp.

I added a github pull request for the stuff in Part 2. Every external project does this differently but part 1 will cause the shutdown deadlock if it lands without part 2. Let me know if you need me to change something.

(In reply to David Parks (dparks) [:handyman] from comment #35)

Upstream. Derp.

I added a github pull request for the stuff in Part 2. Every external project does this differently but part 1 will cause the shutdown deadlock if it lands without part 2. Let me know if you need me to change something.

I reviewed and landed your PR upstream last week (thanks!) - just checking in about landing these patches - anything I can help with?

What's the time frame for integrating the upstream changes? It looks like the last time was Jan 22. I'll need that to land that before part 1 or it will cause shutdown hangs.

I'll land the upstream update in bug 1621428.

The issue is also on Linux (distro: Pop!_OS) on website with infinite scrolling and video on it (like 9gag or else).

It create infinite process for sound until the system can't create more (and no sound anymore on the whole system) and when it happen, Firefox will freeze when opening a NewTab (but tab already opened still work, it will only freeze when opening a new one when the system reach the max Firefox sound process that can be created).

(In reply to David Parks (dparks) [:handyman] from comment #38)

What's the time frame for integrating the upstream changes? It looks like the last time was Jan 22. I'll need that to land that before part 1 or it will cause shutdown hangs.

Part 1 is safe to land now. Part 2 is obsoleted by bug 1621428's landing.

(In reply to mgasser from comment #40)

The issue is also on Linux (distro: Pop!_OS) on website with infinite scrolling and video on it (like 9gag or else).

This bug is about a Windows specific issue. Can you please file a new bug (and CC me) for the issue you're seeing?

Landed. Thanks :kinetik!

https://hg.mozilla.org/mozilla-central/rev/483dac65ecb0